合約文件常識

有了小小的心理建設以後，就是小小的軟體專案合約常識。

合約上的法律條文（這比較不關工程師的事情），一般都採「私法自治原則」，也就是說不違反大原則律法之下，專案的走向完全可以由合約訂定為主，而且強烈建議工程師們就算是接民間案，千萬勿以案小而不簽，就算是一天的工作，也要簽訂簡單的合約，這部分的概念來自於軟體專案顧問的20法則。

軟體專案合約的組成除了法律條文以外最主要的部分就是 RFP (Request For Proposal)，它的定義是「主要功能在載明界定委外工作需求及範疇，預先做好委託機關與有意願之業者間的溝通依據，避免日後合約執行過程中爭議。同時也作為有意願之業者提出建議書之基礎，及提供執行合約驗收之依據。」，而這個叫做 RFP 的東西主要包含了兩個部分

• 軟體規格書
• 供應條件

規格書就是專案一切爆炸案的來源，也是本系列力勸工程師應該要看的主要核心，因為工程師能做的就是確保自己寫出能力所及，並且對客戶來講非常清楚的規格。那工程師應該寫出什麼樣的規格，這部分我預計在本系列後續會另開一篇來討論，在第一篇，我想說的是工程師應該知道自己 為什麼要寫規格：

• 因為你的 PM 很可能他只負責畫大餅
• 因為你的 SA 很可能他只負責系統分析但沒寫過 code
• 因為你的 SD 很可能他只負責把事情推給你

往積極面來想，能夠寫規格也算是提升自己 SD/SA 的能力，但是無論如何，實作的人是工程師，最好的方法還是由工程師最後 review 一下至少和自己部分有關的相關規格，規格中應該要包含非常明確的

1. 該做什麼
2. 何時做完
3. 如何驗收

換句話說，規格完全關係到了整個專案的現金流和死線，最最重要的就是如何驗收，一定要寫清楚，儘量不留灰色地帶 – 要減少灰色地帶，就需要把規格儘量切細。

(簡單來說，就像是寫 BDD 測試的方式，甚至是單元測試，一項一項讓客戶清楚明白「你已經做完了」)

供應條件則是某一些客戶或系統需求必須採購的供應項目，例如本系統需要 Oracle database 11g，採購 License 一年或某某防火牆硬體之類，這部分就比較還好，較少出現爭議。